M08 Network Segmentation and Firewalls
Lecture Videos
Background
Data networks were originally planned to have reachability between communicating parties under any circumstances (e.g. nuclear war). A route between parties could always be found through dynamic routing.
Unfortunately this reachability isn't always welcome. As years gone by have teached us, not every host should be connected to every host.
This restriction of reachability in a data network is typically restricted by a firewall.
Firewalls (and their filters) are the classic example of cyber security. And thus recognizable by a lot of consumers.
Information Security also affected this as Information (or data) is protected throughout its lifespan:
- in use
- on paper
- on a computers desktop
- in transit
- in data networks !!!
- in rest
- on hard drives
- on USB -sticks
Firewalls set up perimeter defence around network segments that can filter traffic going through them. This is no different than a city setting up walls around it to force people traverse through gates of the city.
These filtering decisions are typically installed in a firewall rule table.
Firewall cannot do any of these things if the traffic isn't routed through it!
This means the network administrator must have the capability to handle (and route) network traffic and direct it through the firewall!
Firewalls allow the network to:
- Deny
- Permit
- Reject, deny and send a TCP RST or an ICMP port unreachable message to the source host
- Encrypt/decrypt (direct into a VPN)
- Authenticate (e.g. enforce web portal authentication)
- Prioritize (Input Quality of Service markings such as TOS or DSCP)
- Schedule (insert the traffic into a traffic queue for a scheduler to handle)
- Filter (scrap stuff out from the packet)
- and monitor (log the traffic)
...traffic from one zone to another
Network Segments and Zones
Very often different firewalls discuss of network segments or (policy) zones. There is no established, standard terminology for firewalls. Thus the terminology changes from one product to another.
Is it permit, allow or accept?
Network segment typically means a subnet or a supernet of addresses.
Policy Zone is a group of Network Segments
Example of this could be the LabraNet Classrooms. Lets use D330, D331 and D334 as an example. All of them contain many computers and are subnets of their own:
- D330, 192.168.xx.0/24
- D331, 192.168.yy.0/24
- D334, 192.168.zz.0/24
Given that there are Servers in LabraNet (e.g. student.labranet.jamk.fi)
- servers, 192.168.kk.0/24
The topology would look like this.
The firewall rule table would have a lot of rows.
| Index | From | To | Protocol | Action |
|---|---|---|---|---|
| 01 | D330 | Servers | HTTP | Accept |
| 02 | D331 | Servers | HTTP | Accept |
| 03 | D334 | Servers | HTTP | Accept |
| 04 | Any | Any | Any | Deny |
The Action is the same for all of the Classrooms. Thus the creation of an Array named Classrooms is convinient.
Array's are a part of programming
Classrooms = [D330, D331, D334]
Thus this categorization of network segments would look like the figure below
Resulting in a firewall rule table of
| Index | From | To | Protocol | Action |
|---|---|---|---|---|
| 01 | Classrooms | Servers | HTTP | Accept |
| 02 | Any | Any | Any | Deny |
Imagine how many firewall rows can be saved with the actual amount of classrooms in IT-Dynamo building?
Zoning results to a more readable/understandable firewall rule table
Types of Firewalls
Host-based Firewalls
Many firewall products are on the market for end devices. Nowadays many commercial solutions are called Endpoint Protection solutions that stack multiple solutions next to the firewall functionality, such as antivirus detection, data loss preventation and so on.
Always the basic functionality is that your operating system has a firewall.
A functionality which allows programs to communicate with the data network you have been connected to.
Windows Firewall
Windows Firewall was introduced in Windows XP Service Pack 1 and has thus evolved into a fully functional solution for Windows desktop environments.
Screencapture of Windows Defender Firewall in Windows 10, August 2020
iptables
IPtables is the most commonly used firewall solution of the Linux operating system(s).
Quote
iptables is the userspace command line program used
to configure the Linux 2.4.x and later packet filtering
ruleset. It is targeted towards system administrators.
The iptables package also includes ip6tables. ip6tables
is used for configuring the IPv6 packet filter.
- Source: Netfilter.org
The weakness of iptables is that every protocol has its own xyztables implementation: arptables, ip6tables, iptables, ...
sudo iptables -L from lubuntu.ova
Chain INPUT (policy ACCEPT)
target prot opt source destination
ufw-before-logging-input all -- anywhere anywhere
ufw-before-input all -- anywhere anywhere
ufw-after-input all -- anywhere anywhere
ufw-after-logging-input all -- anywhere anywhere
ufw-reject-input all -- anywhere anywhere
ufw-track-input all -- anywhere anywhere
Chain FORWARD (policy DROP)
target prot opt source destination
ufw-before-logging-forward all -- anywhere anywhere
ufw-before-forward all -- anywhere anywhere
ufw-after-forward all -- anywhere anywhere
ufw-after-logging-forward all -- anywhere anywhere
ufw-reject-forward all -- anywhere anywhere
ufw-track-forward all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ufw-before-logging-output all -- anywhere anywhere
ufw-before-output all -- anywhere anywhere
ufw-after-output all -- anywhere anywhere
ufw-after-logging-output all -- anywhere anywhere
ufw-reject-output all -- anywhere anywhere
ufw-track-output all -- anywhere anywhere
Chain ufw-after-forward (1 references)
target prot opt source destination
Chain ufw-after-input (1 references)
target prot opt source destination
ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:netbios-ns
ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:netbios-dgm
ufw-skip-to-policy-input tcp -- anywhere anywhere tcp dpt:netbios-ssn
ufw-skip-to-policy-input tcp -- anywhere anywhere tcp dpt:microsoft-ds
ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:bootps
ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:bootpc
ufw-skip-to-policy-input all -- anywhere anywhere ADDRTYPE match dst-type BROADCAST
Chain ufw-after-logging-forward (1 references)
target prot opt source destination
LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warning prefix "[UFW BLOCK] "
Chain ufw-after-logging-input (1 references)
target prot opt source destination
Chain ufw-after-logging-output (1 references)
target prot opt source destination
Chain ufw-after-output (1 references)
target prot opt source destination
Chain ufw-before-forward (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere icmp destination-unreachable
ACCEPT icmp -- anywhere anywhere icmp time-exceeded
ACCEPT icmp -- anywhere anywhere icmp parameter-problem
ACCEPT icmp -- anywhere anywhere icmp echo-request
ufw-user-forward all -- anywhere anywhere
Chain ufw-before-input (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ufw-logging-deny all -- anywhere anywhere ctstate INVALID
DROP all -- anywhere anywhere ctstate INVALID
ACCEPT icmp -- anywhere anywhere icmp destination-unreachable
ACCEPT icmp -- anywhere anywhere icmp source-quench
ACCEPT icmp -- anywhere anywhere icmp time-exceeded
ACCEPT icmp -- anywhere anywhere icmp parameter-problem
ACCEPT icmp -- anywhere anywhere icmp echo-request
ACCEPT icmp -- anywhere anywhere icmp echo-request state RELATED,ESTABLISHED
ACCEPT udp -- anywhere anywhere udp spt:bootps dpt:bootpc
ufw-not-local all -- anywhere anywhere
ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns
ACCEPT udp -- anywhere 239.255.255.250 udp dpt:1900
ufw-user-input all -- anywhere anywhere
Chain ufw-before-logging-forward (1 references)
target prot opt source destination
Chain ufw-before-logging-input (1 references)
target prot opt source destination
Chain ufw-before-logging-output (1 references)
target prot opt source destination
Chain ufw-before-output (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere state NEW,RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED
ufw-user-output all -- anywhere anywhere
Chain ufw-logging-allow (0 references)
target prot opt source destination
LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warning prefix "[UFW ALLOW] "
Chain ufw-logging-deny (2 references)
target prot opt source destination
RETURN all -- anywhere anywhere ctstate INVALID limit: avg 3/min burst 10
LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warning prefix "[UFW BLOCK] "
Chain ufw-not-local (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere ADDRTYPE match dst-type LOCAL
RETURN all -- anywhere anywhere ADDRTYPE match dst-type MULTICAST
RETURN all -- anywhere anywhere ADDRTYPE match dst-type BROADCAST
ufw-logging-deny all -- anywhere anywhere limit: avg 3/min burst 10
DROP all -- anywhere anywhere
Chain ufw-reject-forward (1 references)
target prot opt source destination
Chain ufw-reject-input (1 references)
target prot opt source destination
Chain ufw-reject-output (1 references)
target prot opt source destination
Chain ufw-skip-to-policy-forward (0 references)
target prot opt source destination
DROP all -- anywhere anywhere
Chain ufw-skip-to-policy-input (7 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
Chain ufw-skip-to-policy-output (0 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
Chain ufw-track-forward (1 references)
target prot opt source destination
Chain ufw-track-input (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere ctstate NEW
ACCEPT udp -- anywhere anywhere ctstate NEW
Chain ufw-track-output (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere ctstate NEW
ACCEPT udp -- anywhere anywhere ctstate NEW
Chain ufw-user-forward (1 references)
target prot opt source destination
Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
Chain ufw-user-limit (0 references)
target prot opt source destination
LOG all -- anywhere anywhere limit: avg 3/min burst 5 LOG level warning prefix "[UFW LIMIT BLOCK] "
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Chain ufw-user-limit-accept (0 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
Chain ufw-user-logging-forward (0 references)
target prot opt source destination
Chain ufw-user-logging-input (0 references)
target prot opt source destination
Chain ufw-user-logging-output (0 references)
target prot opt source destination
Chain ufw-user-output (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
Iptables in an Android Phone (rooted with cyanogenmod)
nftables
nftables is a competitor to iptables.
nftables commandline alters from iptables
nft add table ip nimi
nft add chain ip nimi forward { type filter hook forward priority 0\; }
nft add chain ip nimi forward { tcp dport 80 ip daddr 1.150.40.100 counter accept \; }
nft add rule ip nimi forward ct state established,related accept
nft insert rule ip nimi forward icmp type {echo-request} accept
nft add chain ip nimi forward { drop\; }
nft add chain ip nimi incoming { type filter hook input priority 0\; }
nft add chain ip nimi incoming { policy drop\; }
nft add chain ip nimi incoming { icmp type {echo-request} accept\; }
nft add chain ip nimi incoming { tcp dport 22 accept\; }
nft list table nimi -a
Uncomplicated Firewall
Ubuntu has a default installation of ufw for users that don't want to learn iptables (nor nftables).
Example of an ufw ruleset on a Raspberry Pi
Network-based Firewalls
Vyos
Vyos has firewall filters functionality to apply traffic restrictions between subnets.
PfSense
Pfsense is an open source firewall solution with a web user interface very commonly preferred for basic network firewall functionality for an organization.
Sophos
Sophos offers XG Firewall Free Trial(s) for virtual machines utizling their software.
Example of Sophos user interface from around ~2016
Source: Laboratory Exercise 3, Jare Ristimäki, Nikke Kettunen, Henri Huuskonen, Meeri Niiranen, Vesse Saastamoinen
Paloalto
Paloalto is the firewall product used in LabraNet.
Example of Paloalto user interface from a few years back
Stateful / Stateless Firewalls
The state table is a dynamic rule table, that reflects accepted traffics bidirectionality.
Meaning that if an traffic is permitted out, the returning traffic in is also permitted/reflected.
Given the topology
The rule table could be
| Index | From | To | Protocol | Action |
|---|---|---|---|---|
| 01 | 1.1.200.0/24 | 1.1.100.0/24 | HTTP | Accept |
| 02 | Any | Any | Any | Deny |
This would mean only traffic from the workstation is allowed to the server.
By reflecting the traffic backwards means that one row is added to the rule table dynamically (thus it looks after the state of the communications).
| Index | From | To | Protocol | Action |
|---|---|---|---|---|
| 01 | 1.1.200.0/24 | 1.1.100.0/24 | HTTP | Accept |
| 02 | 1.1.100.0/24 | 1.1.200.0/24 | HTTP* | Accept |
| 03 | Any | Any | Any | Deny |
Warning
These state tables are hard to syncronize in high availability setups, often requiring cables called 'heartbeat' cables between firewalls to sync the different RAM state tables.
Placing Firewalls
Placing of firewalls is often complicated. Depth in Defence often regulates that end devices need an firewall of their own and network firewalls are also required.
Different protection levels often require multiple network firewalls in place to limit transactions between classified network segments.
Yhdyskäytäväohje, sorry only in finnish
Configuring Vyos with a firewall
Be careful when configuring firewalls!
Gladly we have console access to our firewall VMs (vyosses) through VirtualBox.
But in production use you might configure the devices through a management connection (e.g. SSH or HTTPS)
For some reason everybody has to experience the feeling of firewalling yourself out of your device
No matter how many warnings is given :)
Be wary when you commit
To have our vyos reachable in problem cases, it is good to enable ping globally through all the firewalls.
set firewall all-ping <enable/disable>
After this we can start to setup our zones. Lets use our environment with 3 zones:
- LAN
- interfaces that use private IPv4 addresses
- WAN
- interface that has the public IPv4 address
- vyos
- IPv4 addresses that are local to this vyos
Click here to see this "zonefication" visually in a topology picture!
Zones can be declared by set zone-policy zone <name> default-action <drop/accept>.
By default (as the rule tables typically always have the default drop) we declare them as:
set zone-policy zone LAN default-action drop
set zone-policy zone WAN default-action drop
set zone-policy zone vyos default-action drop
Then we have to declare what interfaces are bound to these zones through set zone-policy zone <name> interface <interface>.
This is important. E.g. Multiple VLANs could be bound to one zone
Verifying that those subnets belong to a zone (e.g. classrooms)
Example with our zones (& topology picture) would be:
set zone-policy zone WAN interface eth0
set zone-policy zone LAN interface eth1
set zone-policy zone LAN interface eth2
set zone-policy zone vyos local-zone
Be precise on the zone-interface binding
e.g. with vif interfaces ... e.g. set zone-policy zone LAN interface eth2.20
After this we can start to make our rule tables based on what zone is discussing with what zone. Lets start with LAN->WAN.
Firewall: LAN->WAN
We want to allow the basic traffic of our course as follows.
Documented rule table:
| Index | From | To | Protocol | Action |
|---|---|---|---|---|
| 10 | LAN | WAN | HTTP (tcp/80) | Accept |
| 11 | LAN | WAN | HTTPS (tcp/443) | Accept |
| 20 | LAN | WAN | ICMP | Accept |
| 30 | LAN | WAN | SSH (tcp/22) | Accept |
| 40 | LAN | WAN | DNS (udp/53) | Accept |
| 999 | Any | Any | Any | Deny |
And as configuration
set firewall name LAN_to_WAN default-action drop
set firewall name LAN_to_WAN enable-default-log
set firewall name LAN_to_WAN rule 10 action accept
set firewall name LAN_to_WAN rule 10 destination port 80
set firewall name LAN_to_WAN rule 10 protocol tcp
set firewall name LAN_to_WAN rule 10 log enable
set firewall name LAN_to_WAN rule 11 action accept
set firewall name LAN_to_WAN rule 11 destination port 443
set firewall name LAN_to_WAN rule 11 protocol tcp
set firewall name LAN_to_WAN rule 11 log enable
set firewall name LAN_to_WAN rule 20 action accept
set firewall name LAN_to_WAN rule 20 protocol icmp
set firewall name LAN_to_WAN rule 20 log enable
set firewall name LAN_to_WAN rule 30 action accept
set firewall name LAN_to_WAN rule 30 destination port 22
set firewall name LAN_to_WAN rule 30 protocol tcp
set firewall name LAN_to_WAN rule 30 log enable
set firewall name LAN_to_WAN rule 40 action accept
set firewall name LAN_to_WAN rule 40 destination port 53
set firewall name LAN_to_WAN rule 40 protocol udp
set firewall name LAN_to_WAN rule 40 log enable
Firewall: WAN->LAN
Lets proceed to WAN->LAN and make the firewall stateful. This means everything that is allowed from LAN->WAN is also allowed back from WAN->LAN.
Documented rule table:
| Index | From | To | Protocol | Action |
|---|---|---|---|---|
| 10 | WAN | LAN | Established sessions | Accept |
| 999 | Any | Any | Any | Deny |
And as configuration
set firewall name WAN_to_LAN default-action drop
set firewall name WAN_to_LAN rule 10 action accept
set firewall name WAN_to_LAN rule 10 state established enable
set firewall name WAN_to_LAN rule 10 state related enable
Firewall: LAN->vyos
LAN networks need to have an SSH connection to the IP addresses that the vyos VM uses. This means the interface addresses of the device. Also the routing protocol (OSPF) needs to be accepted to form routing adjacencies.
Documented rule table:
| Index | From | To | Protocol | Action |
|---|---|---|---|---|
| 10 | LAN | vyos | SSH (tcp/22) | Accept |
| 20 | LAN | vyos | OSPF | Accept |
| 999 | Any | Any | Any | Deny |
And as configuration
set firewall name LAN_to_vyos default-action drop
set firewall name LAN_to_vyos rule 10 action accept
set firewall name LAN_to_vyos rule 10 destination port 22
set firewall name LAN_to_vyos rule 10 protocol tcp
set firewall name LAN_to_vyos rule 20 action accept
set firewall name LAN_to_vyos rule 20 protocol ospf
Firewall: vyos->LAN
The SSH connections need to be accepted back out (to LAN) from the device (from vyos). Also the routing protocol (OSPF) needs to be accepted to form routing adjacencies.
Documented rule table:
| Index | From | To | Protocol | Action |
|---|---|---|---|---|
| 10 | vyos | LAN | Established sessions | Accept |
| 20 | vyos | LAN | OSPF | Accept |
| 999 | Any | Any | Any | Deny |
And as configuration
set firewall name vyos_to_LAN default-action drop
set firewall name vyos_to_LAN rule 10 action accept
set firewall name vyos_to_LAN rule 10 state established enable
set firewall name vyos_to_LAN rule 10 state related enable
set firewall name vyos_to_LAN rule 20 action accept
set firewall name vyos_to_LAN rule 20 protocol ospf
Firewall: vyos->WAN
This last accept might be unnecessary, but to ensure established connections are allowed back to WAN.
This is meant to be an example of Cyber Security in Firewalls
Often as something seems to work and it is not tested if it is necessary...
It is left to production use and might open up an possibility of an attack.
You can test yourself if it is necessary in the exercises!!!
Documented rule table:
| Index | From | To | Protocol | Action |
|---|---|---|---|---|
| 10 | vyos | WAN | Established sessions | Accept |
| 999 | Any | Any | Any | Deny |
And as configuration
set firewall name vyos_to_WAN default-action drop
set firewall name vyos_to_WAN rule 10 action accept
set firewall name vyos_to_WAN rule 10 state established enable
set firewall name vyos_to_WAN rule 10 state related enable
Firewall: WAN->vyos
If the vyos makes connections to outside (note that they aren't allowed in vyos->WAN), we accept the established sessions. Also we ensure our device is reachable through ping (ICMP) for troubleshooting purposes.
Documented rule table:
| Index | From | To | Protocol | Action |
|---|---|---|---|---|
| 10 | WAN | vyos | Established sessions | Accept |
| 20 | WAN | vyos | ICMP | Accept |
| 999 | Any | Any | Any | Deny |
And as configuration
set firewall name WAN_to_vyos default-action drop
set firewall name WAN_to_vyos rule 10 action accept
set firewall name WAN_to_vyos rule 10 state established enable
set firewall name WAN_to_vyos rule 10 state related enable
set firewall name WAN_to_vyos rule 20 action accept
set firewall name WAN_to_vyos rule 20 protocol icmp
Finally binding the firewall rules to traffic between the zones
The way this guide has been written makes sense (hopefully) up to this point. But the naming of our firewalls and their placement into use looks absurd.
set zone-policy zone <destination-zone> from <source-zone> firewall name <source_to_destination>
But trust me, It works if done as follows:
set zone-policy zone LAN from WAN firewall name WAN_to_LAN
set zone-policy zone WAN from LAN firewall name LAN_to_WAN
set zone-policy zone vyos from LAN firewall name LAN_to_vyos
set zone-policy zone LAN from vyos firewall name vyos_to_LAN
set zone-policy zone WAN from vyos firewall name vyos_to_WAN
set zone-policy zone vyos from WAN firewall name WAN_to_vyos
Verifying with outside devices
Warning
Firewalls are tricky to verify.
- This means your connections might be dropped. And you have no idea why.
- This means your connections might be allowed. And you have no idea why.
And it takes a lot of patience and skill to verify the functionality of a firewall.
If you firewall your routing protocol -> the problem might occur from routing
Make sure your routing is working, before you blame your firewall
Be prepared to take out additional drawing material to verify the functionality of your firewall.
The following functionality has been tested in this topology
Verifying HTTP from LAN to WAN
Setup a Lubuntu device in LAN and make it connect to HTTP in WAN.
As the page loads... HTTP is working!
Same can be verified with wget -command
lubuntu@lubuntu-virtualbox:~$ wget 25.0.0.3
--2020-08-26 09:31:38-- http://25.0.0.3/
Connecting to 25.0.0.3:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 11010 (11K) [text/html]
Saving to: ‘index.html’
index.html 100%[================================================>] 10,75K 10,3KB/s in 1,0s
2020-08-26 09:31:40 (10,3 KB/s) - ‘index.html’ saved [11010/11010]
lubuntu@lubuntu-virtualbox:~$
If the index.html works... HTTP is working!
Verifying ping from LAN to WAN
Use the same Lubuntu device in LAN and make it ping to WAN.
lubuntu@lubuntu-virtualbox:~$ ping 25.0.0.3
PING 25.0.0.3 (25.0.0.3) 56(84) bytes of data.
64 bytes from 25.0.0.3: icmp_seq=1 ttl=62 time=2.25 ms
64 bytes from 25.0.0.3: icmp_seq=2 ttl=62 time=2.14 ms
64 bytes from 25.0.0.3: icmp_seq=3 ttl=62 time=2.49 ms
64 bytes from 25.0.0.3: icmp_seq=4 ttl=62 time=2.29 ms
^C
--- 25.0.0.3 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 2.140/2.291/2.491/0.127 ms
lubuntu@lubuntu-virtualbox:~$
Verifying traceroute from LAN to WAN
The default traceroute utilizes UDP and is doomed to fail as it isn't allowed through the firewall.
lubuntu@lubuntu-virtualbox:~$ traceroute 25.0.0.3
traceroute to 25.0.0.3 (25.0.0.3), 64 hops max
1 192.168.10.254 1,356ms 1,284ms 0,856ms
2 10.0.2.2 1,584ms 1,205ms 1,026ms
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * ^C
lubuntu@lubuntu-virtualbox:~$
Adding --icmp solves this problem and works! As ICMP is allowed through the firewall.
lubuntu@lubuntu-virtualbox:~$ traceroute --icmp 25.0.0.3
traceroute to 25.0.0.3 (25.0.0.3), 64 hops max
1 192.168.10.254 1,351ms 0,688ms 1,086ms
2 10.0.2.2 1,499ms 1,419ms 1,310ms
3 25.0.0.3 1,447ms 1,302ms 1,283ms
using nmap to verify firewalling
Use the same Lubuntu device in LAN to use network map (nmap) to WAN.
lubuntu@lubuntu-virtualbox:~$ sudo nmap -sS 25.0.0.3
[sudo] password for lubuntu:
Starting Nmap 7.80 ( https://nmap.org ) at 2020-08-26 09:26 EEST
Nmap scan report for 25.0.0.3
Host is up (0.0020s latency).
Not shown: 997 filtered ports
PORT STATE SERVICE
22/tcp closed ssh
80/tcp open http
443/tcp closed https
Nmap done: 1 IP address (1 host up) scanned in 5.05 seconds
Verifying with show commands
show log firewall name LAN_to_WAN showing accepted packet
Notice the LAN_to_WAN-10-A which dictates that rule 10 accepted
vyos@vyos:~$ show log firewall name LAN_to_WAN
Aug 21 12:29:16 vyos kernel: [18330.405794] [LAN_to_WAN-10-A] IN=eth2 OUT=eth3
MAC=08:00:27:89:07:23:08:00:27:27:8e:31:08:00 SRC=192.168.10.9 DST=25.0.0.3
LEN=52 TOS=0x00 PREC=0x00 TTL=62 ID=19840 DF PROTO=TCP SPT=59884 DPT=80
WINDOW=501 RES=0x00 ACK FIN URGP=0
show log firewall name LAN_to_WAN showing dropped/denied packet
Notice the LAN_to_WAN-default-D which dictates that default-action dropped
This was a traceroute which utilized UDP/33438, which wasn't allowed on any of our rules.
vyos@vyos:~$ show log firewall name LAN_to_WAN
Aug 21 12:31:08 vyos kernel: [18442.659929] [LAN_to_WAN-default-D]IN=eth2 OUT=eth3
MAC=08:00:27:89:07:23:08:00:27:27:8e:31:08:00 SRC=192.168.10.9 DST=25.0.0.3
LEN=37 TOS=0x00 PREC=0x00 TTL=3 ID=42867 DF PROTO=UDP SPT=50269 DPT=33438 LEN=17
vyos@vyos:~$
Continue to the Exercises
Back to the Schedule?
License
This course and its materials are written by Karo Saharinen and licenced by Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0) license.
